Briefly browsing through the rest of the approaches, it seems like my solution uses yet another approach. Maybe I'll add an approach doc for it after I finish auditing all of the others.

Thought I'd start with a read-through. Looking good so far. PSA: Don't forget to add yourself as a contributor for any approach that you fix/edit. 😄

I'll come back and do another once you're ready.

That will probably be sometime tomorrow, considering that it's getting pretty late in my timezone.

Briefly browsing through the rest of the approaches, it seems like my solution uses yet another approach. Maybe I'll add an approach doc for it after I finish auditing all of the others.

awesome sauce! I love it. The more approaches, the better. I find that a wide variety teaches a TON of things. It can become an obsession. 😉

Question: Some terms are referred to in multiple ways, such as "while-loop" vs "while loop" and "list-comprehension" vs "list comprehension". Which version should be used?

Variation 2 doesn't seem to work? It uses match as a variable, but it is a keyword. And even if I fix that, isn't it processing the operations in the wrong order?

This one? When I put it into the online editor, it was complaining about an indentation error. I went back over it, and the version below now passes all the tests.

import re
from operator import add, mul, sub
from operator import floordiv as div

DIGITS = re.compile(r"-?\d+")
OPERATORS = (
    (mul, re.compile(r"(?P<x>.*) multiplied by (?P<y>.*)")),
    (div, re.compile(r"(?P<x>.*) divided by (?P<y>.*)")),
    (add, re.compile(r"(?P<x>.*) plus (?P<y>.*)")),
    (sub, re.compile(r"(?P<x>.*) minus (?P<y>.*)")),
    )

def answer(question):
    if not question.startswith( "What is") or "cubed" in question:
        raise ValueError("unknown operation")
    
    question = question.removeprefix( "What is").removesuffix("?").strip()

    if not question:
        raise ValueError("syntax error")
    
    return calculate(question)

def calculate(question):
    if DIGITS.fullmatch(question):
        return int(question)
        
    for operation, pattern in OPERATORS:
        if match := pattern.match(question): #<-- The walrus operator assigns the new re match to `match` each loop.
            return operation(calculate(match['x']), calculate(match['y']))#<-- the loop is paused here to make the two recursive calls.
    raise ValueError("syntax error")

Careful of that match "variable". match is indeed a keyword when you use it with a match-case. BUT it is a "soft keyword" - which means it can still be used as a name in places where it won't get confused with match-case (a.k.a. where it isn't followed by indents and case). Soft keywords are sorta terrible, but I get why it happened. I can't find the docs at the moment, but the discussion around match-case had folx concerned about making them hard keywords, since there was 20+ years of code that potentially used those as identifiers, so would break if they became fully reserved.

Also note that this uses a walrus operator, which means the value of match is changing with every call to calculate().

If it is calculating in the wrong order, at least a few of the tests should have failed. But this is also a very complex solution, since it has two recursive branches in a loop. IIRC, when I was going over this, I had to put it into python tutor and walk it to make sure I really understood the recursive calls in the loop.

This actually came from Isaac. You can see his solution variations here. The recursion in a loop variants are the first three, I think.

This approach has an unnecessary else after the return for the base case in calculate(). Pylint reports "R1705 no-else-return" and suggests removing it, and I agree 😆.

Yup. Definitely cleaner that way (I should listen to PyLint more often). I need to update my published solution! 😆

from operator import add, mul, sub
from operator import floordiv as div

# Define a lookup table for mathematical operations
OPERATIONS = {"plus": add, "minus": sub, "multiplied": mul, "divided": div}


def answer(question):
    # Call clean() and feed it to calculate()
    return calculate(clean(question))

def clean(question):
    # It's not a question unless it starts with 'What is'.
    if not question.startswith("What is") or "cubed" in question:
        raise ValueError("unknown operation")

    # Remove the unnecessary parts of the question and
    # parse the cleaned question into a list of items to process.
    # The wrapping () invoke implicit concatenation for the chained functions
    return (question.removeprefix("What is")
            .removesuffix("?")
            .replace("by", "")
            .strip()).split() # <-- this split() turns the string into a list.

# Recursively calculate the first piece of the equation, calling 
# calculate() on the product + the remainder.
# Return the solution when len(equation) is one.
def calculate(equation):
    if len(equation) == 1:
        return int(equation[0])

    try:
        # Unpack the equation into first int, operator, and second int.
        # Stuff the remainder into *rest
        x_value, operation, y_value, *rest = equation

        # Redefine the equation list as the product of the first three
        # variables concatenated with the unpacked remainder.
        equation = [OPERATIONS[operation](int(x_value),
                                          int(y_value)), *rest]
    except:
        raise ValueError("syntax error")

    # Call calculate() with the redefined/partially reduced equation.
    return calculate(equation)

Careful of that match "variable". match is indeed a keyword when you use it with a match-case. BUT it is a "soft keyword" - which means it can still be used as a name in places where it won't get confused with match-case (a.k.a. where it isn't followed by indents and case).

I see. I didn't know about soft keywords.

If it is calculating in the wrong order, at least a few of the tests should have failed.

Turns out there actually isn't a test for the case that I'm thinking of! There are no questions in the test suite with at least three operations/four numbers in them.

This pythontutor link should show the case I'm talking about.

You can see that since it parses the expression in the wrong order, it returns 9 instead of -31.

Turns out there actually isn't a test for the case that I'm thinking of! There are no questions in the test suite with at least three operations/four numbers in them.

This pythontutor link should show the case I'm talking about.

You can see that since it parses the expression in the wrong order, it returns 9 instead of -31.

This is an excellent catch!!. Methinks we should add some additional track-specific test cases for this exercise. NICE WORK!!!

Here are my current thoughts:

1. We get all the small changes and corrections done for this.
2. We change the explanation for Variation 2 to point at a failure to generalize, due to items being processed in the incorrect order.
3. We (attempt) to correct the code so that it does process in the correct order (not sure we can do that with the looped recursion, but we can try) and add it to the approach.
4. We test the other approaches for the same issue (since we have a hole in test coverage that is significant)
5. We add several additional test cases in the additional test case JSON, to cover this hole
6. If the example for this exercise also fails the new test cases, we might want to start a discussion on the forum about missing test cases in the canonical data. I'd wait to do this to make absolutely sure that a large number of solutions across programming languages would fail the new cases, otherwise you'll get denied.

Make sense? 😄

I think so! Number 5 would be in a separate PR, right?

I think so! Number 5 would be in a separate PR, right?

Yuppers. A tad more involved than it looks, since we need to also regenerate the test file, may or may not need to adjust the test template (likely not), and do some re-tests on the example.

And 6 would be an entirely different repo, Problem Specs with likely a long discussion among maintainers on the forum first. For that, you'll want some illustrative examples from both Python and other languages.

Let's get the major changes here merged, and then I can walk you through the test generation/template/additional tests thing. If that's OK?

Sounds good!

The last two approaches basically just had the same kind of errors that were present in the previous ones. Though the very last one was also too compact, so I expanded it so it would be readable.

@BethanyG, that's numbers 1 and 2 done; now it should be time for 3 and 4. I'm not quite sure how to go about doing these, however.

Especially number 3... That variant is super complicated.

@BethanyG, that's numbers 1 and 2 done; now it should be time for 3 and 4. I'm not quite sure how to go about doing these, however.

Especially number 3... That variant is super complicated.

Oh! I am so sorry! Somehow, past a certain point, comments don't seem to be triggering new notifications for me. I was head's down on fixing classes (spoiler: it might go the way of that other one), and didn't get pinged.

Give me a few, and let me see if I can take a crack. 😄

As for 4, are you testing locally with PyTest, or using the website? If you are testing locally, we can do a special hand-edit to the test file and you can then use that for the other approaches.

If not...well, time to learn how to set up a local testing env with PyTest. 😉

Ping me on the forum or Discord, and I can walk you through. I don't trust GH at the moment. 😡

Give me a few, and let me see if I can take a crack. 😄

Today, children, we are going to learn about positive lookaheads in regex 🤦🏽‍♀️ . I mean, why not? I don't really need those neurons, do I?

Big, green button or a cooling-off period?